Больше 5 лет назад мы писали о технологии VMware Storage I/O Control (SIOC), которая позволяет приоритизировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены. С тех пор многие администраторы применяют SIOC в производственной среде, но не все из них понимают, как именно это работает.

На эту тему компания VMware написала два интересных поста (1 и 2), которые на практических примерах объясняют, как работает SIOC. Итак, например, у нас есть вот такая картинка:

В данном случае мы имеем хранилище, отдающее 8000 операций ввода-вывода в секунду (IOPS), к которому подключены 2 сервера ESXi, на каждом из которых размещено 2 виртуальных машины. Для каждой машины заданы параметры L,S и R, обозначающие Limit, Share и Reservation, соответственно.

Напомним, что:

• Reservation - это минимально гарантированная производительность канала в операциях ввода-вывода (IOPS). Она выделяется машине безусловно (резервируется для данной машины).
• Shares - доля машины в общей полосе всех хостов ESXi.
• Limit - верхний предел в IOPS, которые машина может потреблять.

А теперь давайте посмотрим, как будет распределяться пропускная способность канала к хранилищу. Во-первых, посчитаем, как распределены Shares между машинами:

Общий пул Shares = 1000+2500+500+1000 = 5000

Значит каждая машина может рассчитывать на такой процент канала:

VM1 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS
VM2 = 2500/5000 = 50% = 0,5 * 8000 = 4000 IOPS
VM3 = 500/5000 = 10% = 0,1 * 8000 = 800 IOPS
VM4 = 1000/5000 = 20% = 0,2 * 8000 = 1600 IOPS

Если смотреть с точки зрения хостов, то между ними канал будет поделен следующим образом:

ESX1 = 3500/5000 = 70%
ESX2 = 1500/5000 = 30%

А теперь обратимся к картинке. Допустим у нас машина VM1 простаивает и потребляет только 10 IOPS. В отличие от планировщика, который управляет памятью и ее Shares, планировщик хранилищ (он называется mClock) работает по другому - неиспользуемые иопсы он пускает в дело, несмотря на Reservation у это виртуальной машины. Ведь он в любой момент может выправить ситуацию.

Поэтому у первой машины остаются 1590 IOPS, которые можно отдать другим машинам. В первую очередь, конечно же, они будут распределены на этом хосте ESXi. Смотрим на машину VM2, но у нее есть LIMIT в 5000 IOPS, а она уже получает 4000 IOPS, поэтому ей можно отдать только 1000 IOPS из 1590.

Следовательно, 590 IOPS уйдет на другой хост ESXi, которые там будут поделены в соответствии с Shares виртуальных машин на нем. Таким образом, распределение IOPS по машинам будет таким:

VM1 = 10 IOPS
VM2 = 4000+1000 = 5000 IOPS (так как установлен Limit)
VM3 = 800 + ((500/1500) * 590) = 997 IOPS
VM4 = 1600 + ((1000/1500) * 590) = 1993 IOPS

Все просто и прозрачно. Если машина VM1 начнет запрашивать больше канала, планировщик mClock начнет изменять ситуацию и приведет ее к значениям, описанным выше.

Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.

В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:

Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.

Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.

Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:

Смотрим, что получится и нажимаем Ok:

Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:

Этой статьёй я хочу открыть серию статей, целью каждой из которых будет описание одной из написанных мной функций PowerCLI или так называемых командлетов (cmdlets), предназначенных для решения задач в виртуальных инфраструктурах, которые невозможно полноценно осуществить с помощью только лишь встроенных функций PowerCLI. Все эти функции будут объединены в один модуль - Vi-Module. Как им пользоваться, можете почитать здесь.

Спустя весьма продолжительное время с момента релиза новой версии платформы vSphere 6.0, компания VMware выпустила обновленную версию статьи базы знаний KB 2131180, в которой приведена схема со всеми портами и соединениями, используемыми в виртуальной инфраструктуре.

Штука это очень полезная и прямо просится на стенку в виде плаката в помещение, где сидят администраторы VMware vSphere. На страницах с 3 по 9 находится таблица со всеми соединениями, где указаны номера портов, протокол, источник и целевой компонент, а также назначение соединения.

Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.

Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.

Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.

К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.

Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:

Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.

Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.

Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.

Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!

Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:

В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).

Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.

Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:

Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:

Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:

Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.

Еще в самом конце августа компания VMware выпустила весьма достойный внимания документ "VMware vCenter Server Performance and Best Practices", рассказывающий о лучших практиках по использованию сервера vCenter версии 6 в контексте производительности. Напомним, что ранее мы уже писали про еще один документ о vCenter - "VMware vCenter Server 6.0 Cluster Performance".

Основные моменты документа:

• vCenter Server 6.0 имеет существенно большую производительность, чем предыдущая версия vCenter Server 5.5. Некоторые операции исполняются почти в 2 раза быстрее, а отображение страниц в Web Client работает на 90% быстрее.
• vCenter Server Appliance работает почти так же быстро, как и полноценный vCenter Server для Windows.
• Ресурсы, выделенные для vCenter (CPU, память, диск и полоса пропускания сети) влияют на размер доступного в vCenter окружения и скорость исполнения операций.
• Используя рекомендации из документа и правильно выделяя ресурсы в зависимости от нагрузки, пользователи могут значительно повысить производительность стандартной конфигурации VMware vCenter.

Скачать документ "VMware vCenter Server Performance and Best Practices" можно по этой ссылке.

Совсем недавно компания VMware выпустила интересный документ о производительности операций виртуальной инфраструктуры под управлением VMware vCenter 6 для серверов, работающих в кластере HA/DRS - "VMware vCenter Server 6.0 Cluster Performance".

Упор сделан на сравнение производительности свежей версии vCenter 6.0 с предшественником - vCenter 5.5. Напомним, что шестая версия поддерживает до 64 хоста ESXi в кластере и до 8000 виртуальных машин (до этого было 32 хоста ESXi и 3000 виртуальных машин).

Конфигурация тестовой среды была следующей:

Программные компоненты:

Производительность каких операций проверялась:

• Add Port Group
• Remove Port Group
• Clone VM
• Create Folder
• Delete Folder
• Create Snapshot
• Delete Snapshot
• Group Power-On VMs
• vMotion VM
• Power On VM
• Power Off VM
• Reconfigure VM
• Register VM
• Unregister VM
• Relocate VM
• Remove VM
• Reset VM
• Suspend VM
• Resume VM

В результате тестирования были получены следующие результаты:

• vCenter 6.0 показывает лучшую операционную производительность (в количестве операций) до 66% лучше прошлой версии.

• Улучшенная производительность под очень тяжелыми нагрузками.
• Одинаковая производительность как vCenter Server для Windows, так и виртуального модуля vCSA на базе Linux.
• Операции с виртуальными машинами происходят существенно быстрее.

Больше интересных подробностей и графиков вы можете найти в документе.

Продолжаем вас знакомить с анонсами прошедшей недавно конференции VMware VMworld 2015. Напомним наши прошлые новости о продуктах и технологиях VMware:

• Улучшения VMware vCloud Air: Project SkyScraper и другие
• Новые возможности VMware Site Recovery Manager 6.1
• Анонсирован VMware Virtual SAN 6.1 - новые возможности
• Новые возможности VMware Horizon View 6.2 для инфраструктуры виртуальных ПК и поддержка NVIDIA GRID 2.0

Сегодня мы расскажем о VMware Cloud Native Applications - стратегии VMware по распространению облачных приложений в контейнерах. Концепция эта основана на двух проектах, которые, возможно, были известны некоторым из вас ранее - Project Bonneville/Pacific и Photon/Lightwave. О проектах Photon и Lightwave мы уже писали вот тут. А вот про Project Bonneville можно почитать здесь.

Напомним, что Photon - это Linux-платформа с минимально необходимым набором средств для запуска контейнеризованных приложений, средств управления средой и взаимодействия с гипервизором VMware vSphere (сейчас минимальная конфигурация этого дела весит около 25 МБ):

Состоит данная среда из двух компонентов: Photon Controller, управляющий развертыванием новых экземпляров виртуальных машин и аутентификацией пользователей (Lightwave), а также Photon Machine - собственно хост, позволяющий запускать экземпляры виртуальных машин с контейнерами приложений (на базе "микровизора" ESX, совместимого по железу с обычным ESXi):

Сама технология использования контейнеризованных приложений называется vSphere Integrated Containers (VIC), она позволяет на базе Photon OS запускать контейнеризованные приложения в среде VMware, включая приложения упакованные средствами Docker.

Photon Controller использует механизм VMFork (сейчас эта технология называется VMware Instant Clone и доступна в vSphere 6) для создания мгновенных экземпляров виртуальных машин (менее 1 секунды) с нужным приложением по запросу от пользователя. Интересно, что в одном экземпляре ВМ работает только один контейнер приложения, что как бы несколько странно для контейнерной виртуализации, но так себе видит эту тему VMware.

Уверяют, что для этой технологии можно будет использовать те же самые серверы, на которых сейчас работает ESXi.

Средство VMware Photon Controller выйдет уже совсем скоро, а вот закрытая бета VMware Photon Platform и Pivotal Cloud Foundry and Photon Platform (интегрированная инфраструктура Photon в PaaS-платформу от VMware) выйдет ближе к концу года:

Более подробно о VMware Cloud-Native Apps рассказано на этой странице. Ну а для тех, кто хочет погрузиться в технические детали, есть вот такая презентация с VMworld 2015:

На днях компания Parallels, которая в основном вам сейчас известна по средствам контейнерной виртуализации Virtuozzo (сейчас это компания Odin), а также продуктам для виртуализации на Mac, выпустила обновленную версию своей настольной платформы виртуализации для Mac OS X - Parallels Desktop 11.

Теперь Parallels Desktop представлен в трех версиях - Parallels Desktop 11 для Mac, Parallels Desktop для Mac Business Edition (ранее он назывался Enterprise Edition), а также новое издание для разработчиков, дизайнеров и профессиональных пользователей — Parallels Desktop для Mac Pro Edition. В качестве хостовой ОС новая версия платформы поддерживает недавно вышедшую ОС Windows 10 и еще не вышедшую Mac OS El Capitan.

Посмотрим на новые функции и улучшения платформы Parallels Desktop 11, которых набралось предостаточно:

Parallels Desktop 11 для Mac

• Работа виртуального помощника Microsoft Cortana в приложениях Mac, даже если окно Windows 10 не активно (находится позади других окон).
• Quick Look для предварительного просмотра документов и файлов Windows.
• Поддержка жестов Force Touch для быстрого просмотра файлов с помощью Quick Look или поиска определения для незнакомого слова.
• Улучшенные элементы управления Mac в Windows, в том числе новая кнопка "Режим Coherence".
• Для приложений Windows, как и для приложений OS X, в панели Dock при клике на правую кнопку мыши теперь показывается список последних файлов, с которыми работал пользователь.
• Удобная печать с поддержкой всех настроек принтера Mac: экономит время и не требует дополнительных навыков от пользователей OS X.
• Меню "Новый файл" для создания файлов в Windows-приложениях, таких как Microsoft Outlook, Microsoft Excel и Microsoft Word.
• Сервисы геолокации в Mac теперь доступны и для Windows-приложений.
• Автоматическая синхронизация установок громкости в виртуальной машине и в Mac.
• Расширенная ассоциация файлов с помощью «умных» уведомлений, которая позволяет назначить программу, которой нужно открыть данный файл, в OS X.
• Улучшения в поддержке виртуальных машин на базе Boot Camp.

Parallels Desktop 11 для Mac Pro Edition включает в себя функции обычного издания плюс следующее:

• Поддержка основных инструментов разработчика - Docker, Chef, Jenkins, подключаемого модуля Visual Studio, Vagrant и других.
• Дополнительные профили пользователей для разработчиков, продвинутых пользователей и тестировщиков для оптимальной конфигурации под их сценарии использования.
• Расширенные сетевые инструменты и конфигурации для виртуальных сетей для тестирования сложных сетевых сценариев, в том числе симуляции неустойчивости сети.
• Доступ к облачным хранилищам данных (Box.net, Dropbox for Business и OneDrive Business) для совместного доступа к файлам Windows на Mac.
• Режим без графического пользовательского интерфейса для запуска виртуальных машин в фоновом режиме.
• Создание связанных клонов для экономии дискового пространства и оптимизации установок.
• Расширенная память (64 ГБ ОЗУ) и мощность процессора (16 виртуальных ЦП).
• Вложенная виртуализация для гостевых ОС Linux.
• Тестовые среды Modern.IE в новом мастере создания виртуальных машин с доступом к бесплатным пробным версиям браузеров для тестирования.

Также интересно, что Parallels предоставляет возможность обновления Parallels Desktop 9 и 10 до Parallels Desktop 11 для Mac Pro Edition за 2490 рублей в год. Техподдержка для Pro Edition осуществляется в режиме 24/7 по телефону и электронной почте.

Parallels Desktop 11 для Mac Pro Edition включает в себя функции бизнес-издания плюс следующее:

• Централизованное администрирование и управление виртуальными машинами.
• Веб-портал для управления лицензиями с единым ключом активации, что исключает необходимость ручного управления индивидуальными лицензионными ключами.
• Поддержка бизнес-уровня, включая круглосуточную приоритетную помощь по телефону и электронной почте.
• Применение политики в отношении USB-устройств для дополнительной защиты.

Скачать Parallels Desktop 11 или обновиться с предыдущей версии продукта можно по этой ссылке.

Каждый администратор VMware vSphere рано или поздно сталкивается с тем, что хост VMware ESXi выпадает в "Pink Screen of Death" (PSOD - розовый экран смерти):

Причина этого - как правило, аппаратные проблемы сервера (барахлящее оборудование, битые блоки памяти, проблемы с драйверами, в том числе виртуальных устройств, и т.п.). В этом случае полезно погуглить ошибку, но сначала нужно получить дамп ядра (core dump), где сохраняются подробности о причине PSOD.

В VMware vSphere Web Client в представлении Hosts and Clusters нажимаем правой кнопкой на сервере vCenter, далее в контекстном меню выбираем пункт "Export System Logs...":

Далее выбираем интересующий нас хост VMware ESXi:

Затем отчекиваем все галки, кроме CrashDumps:

После экспорта файла открываете его в текстовом редакторе и ищете строчку "@bluescreen":

Ниже вы увидите подробности о произошедшей ошибке:

В данном случае мы видим, что имеет место проблема с драйвером виртуального сетевого адаптера (vNIC) E1000. Можно заменить его на VMXNET3 (как описано в KB 2059053), и проблема уйдет. Ну и прочие подобные ошибки можно гуглить, по PSOD ESXi уже есть много информации на форумах.

Многие из вас в курсе, что на сайте проетка VMware Labs есть расширения PowerCLI Extensions (о них мы писали вот тут), позволяющие получить доступ к командлетам PowerCLI/PowerShell, которые еще не выпущены в релиз и доступны только в экспериментальном режиме.

На днях PowerCLI Extensions были обновлены, оттуда убрали командлеты относящиеся к VSAN, так как они были включены в релизную версию PowerCLI 6.0 R1. Но самое интересное, что в PowerCLI Extensions добавили экспериментальные командлеты функций Instant Clone. На самом деле, это фича VM Fork или Project Fargo, о которой мы писали вот тут.

Суть технологии VMFork такова, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в шаренную память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ.

Вот эти командлеты в обновленных PowerCLI Extensions:

В рамках процесса создания мгновенного клона дочерняя ВМ появляется на свет без изначальной загрузки. В процессе работы VMFork происходит кратковременное "подвешивание" родительской ВМ (quiescence) с помощью технологии "fast suspend resume" (FSR), после чего дочерняя ВМ "отцепляется" от родительской, приобретая свою сетевую идентификацию (IP-адрес, маску и т.п.). При этом ВМ шарят общие ресурсы на чтение и имеют свои уникальные области на запись - это очень удешевляет стоимость ресурсов в перерасчете на одну ВМ на хосте.

Сначала сетевые параметры клона задаются следующим массивом:

$configSettings = @{
'ipaddress' = "10.134.14.75";
'netmask' = '255.255.255.0';
'gateway' = '10.134.14.253';
}

Затем мы делаем Instant Clone машины следующей командой:

$childForkVm = New-InstantCloneVM -ParentVM $parentforkVm -Name "2012ChildClone$_" -ConfigParams $configSettings

Это позволяет мгновенно получить свою новую, независимую виртуальную машину, которая имеет свою сетевую идентификацию и диски. Так как в машине стоят VMware Tools, то можно проверить новые настройки с помощью вызова VMware Tools RPCTool:

• "%programfiles%\vmware\vmware tools\rpctool" "info-get guestinfo.fork.ipaddress"
• "%programfiles%\vmware\vmware tools\rpctool" "info-get guestinfo.fork.netmask"
• "%programfiles%\vmware\vmware tools\rpctool" "info-get guestinfo.fork.gateway"

На видео ниже проверяются настройки ВМ, которую собираются клонировать, затем вызываются PowerCLI-команды, чтобы получить 9 мгновенных клонов (у автора видео это заняло 15 секунд):

Потенциально это очень полезная технология, особенно для сред разработки и тестирования. Скачать VMware PowerCLI Extensions с функциями VMware Instant Clone можно по этой ссылке.

Недавно компания VMware выпустила очень интересный документ "What’s New in VMware vSphere 6 - Performance", в котором рассказывается о том, какие улучшения были сделаны в новой версии vSphere 6.0, касающиеся различных аспектов производительности платформы (вычислительные ресурсы, хранилища и сети).

Документ выпущен отделом технического маркетинга VMware, и в нем приведены вполне конкретные сведения об увеличении производительности компонентов vSphere.

Например, вот сводная картинка улучшения производительности vCenter (версия 6.0 против 5.5) при тяжелых нагрузках на Microsoft SQL Server 2012 в зависимости от числа объектов, которые находятся под управлением сервиса (размер Inventory). Данные приведены в количестве операций в минуту. Результаты впечатляют:

Улучшения кластеров отказоустойчивых хранилищ VMware Virtual SAN (результаты по конфигурации All-Flash еще не обработаны):

С точки зрения производительности виртуальных сетевых адаптеров VMXNET 3, платформа vSphere 6.0 научилась выжимать из них более 35 гигабит в секунду при работе с физическими адаптерами 40 GbE:

Ну и в целом в документе есть еще много чего интересного - скачивайте.

На одном из блогов о виртуализации на платформе VMware появилась интересная утилита VLANidentificator, предоставляющая информацию о принадлежности всех ваших виртуальных машин к портгруппам виртуальных коммутаторов и их VLAN ID:

Вы просто вводите стартовый IP-адрес и подсеть для сканирования, а скрипт пробегается по всем хостам VMware ESXi и vCenter, после чего все данные помещаются в сводную таблицу, в которой вы можете проверить, что нужные машины находятся в нужных VLAN, а также посмотреть на каких хостах ESXi они сейчас размещены. Для показа полной информации о машине, в том числе IP-адреса, нужно чтобы в ВМ были установлены VMware Tools.

Утилитка требует PowerShell 3 и более поздней версии и протестирована для работы с VMware vSphere 5.0, поэтому с шестой версией вполне может не работать. Поддерживаются также и распределенные виртуальные коммутаторы VMware Distributed Switch (vDS).

Исполняемый файл VLANidentificator можно скачать по этой ссылке. Ну а исходный код можно скачать вот тут.

Послезавтра, 21 июля, компании Mellanox и StarWind проведут интересный вебинар "100 GbE Performance at 10 GbE Cost", посвященный построению решения для хранилищ виртуальных машин впечатляющей производительности (да-да, 100 GbE, Карл!).

Мероприятие пройдет 21 июля, в 21-00 по московскому времени:

Приходите на вебинар, чтобы узнать, как по цене 10 GbE-решения построить сеть 40 GbE на базе продуктов Mellanox (Infiniband/Ethernet) и добиться в ней 100 GbE производительности за счет решений компании StarWind (в частности, продукта Virtual SAN). Вебинар со стороны StarWind проводит Макс Коломейцев, так что вы можете задавать вопросы на русском языке.

Узнайте, сколько IOPS может выжать StarWind из сетевой архитектуры Mellanox - регистрируйтесь на вебинар "100 GbE Performance at 10 GbE Cost".

Наши постоянные читатели помнят, что еще в 2009 году компания VMware анонсировала Project Onyx, предназначенный для записи действий пользователя в клиенте vSphere и их перекладывания на язык сценариев PowerShell. Также какое-то время назад на сайте проекта VMware Labs появилась утилита Onyx, которая проксировала команды от vSphere Client к серверу vCenter и записывала их как PowerCLI-скрипт (сейчас ее страница переехала вот сюда).

Ну а на днях компания VMware выпустила техническое превью Onyx for the Web Client, который уже позволяет начать запись действий пользователя и получить готовый сценарий прямо в веб-клиенте vSphere.

После установки Onyx for the Web Client появится иконка утилиты в домашнем меню веб-клиента:

Далее просто нажимаем кнопку записи (Start), после чего выполняем нужные нам действия в Web Client:

И получаем на выходе готовый сценарий для исполнения того же самого действия через PowerCLI:

Полученный сценарий можно сохранить:

Классная штука и просто находка для тех, кто хочет все автоматизировать в своей виртуальной инфраструктуре. Скачать Onyx for the Web Client можно по этой ссылке. Инструкции по установке находятся здесь. Поставить его можно как на vCenter Server Appliance, так и на vCenter Server для Windows.

Если вы администратор платформы виртуализации VMware vSphere, то, наверное, часто замечали, что в некоторых случаях при операциях с виртуальными машинами и ее дисками происходит "подмораживание" ВМ (или "stun", он же "quiescence"). В этот момент виртуальная машина ничего не может делать - она недоступна для взаимодействия (в консоли и по сети), а также перестает на небольшое время производить операции ввода-вывода. То есть, ее исполнение ставится на паузу на уровне инструкций, а на уровне ввода-вывода совершаются только операции, касающиеся выполняемой задачи (например, закрытие прежнего VMDK-диска и переключение операций чтения-записи на новый диск при операциях со снапшотами).

Cormac Hogan написал на эту тему интересный пост. Stun виртуальной машины нужен, как правило, для того, чтобы сделать ее на время изолированной от окружающего мира для выполнения значимых дисковых операций, например, консолидация снапшотов. Это может занимать несколько секунд (и даже десятков), но часто это происходит на время около секунды и даже меньше.

Когда может возникать stun виртуальной машины? Есть несколько таких ситуаций.

1. Во время операции "suspend" (постановка ВМ на паузу). Тут происходит такое подмораживание, чтобы скинуть память ВМ на диск, после чего перевести ее в приостановленное состояние.

2. В момент создания снапшота. Об этом написано выше - нужно закрыть старый диск и начать писать в новый. На время этой операции логично, что приостанавливается ввод-вывод.

3. Консолидация снапшотов (удаление всех). Здесь тоже нужно "склеить" все VMDK-диски (предварительно закрыв) и начать работать с основным диском ВМ. А вот удаление снапшота в цепочке stun не вызывает, так как не затрагивает VMDK, в который сейчас непосредственно идет запись.

4. Горячая миграция vMotion. Сначала память передается от одной машины к целевой ВМ без подмораживания, но затем происходит такой же stun, как и при операции suspend, с тем только отличием, что маленький остаток памяти (минимальная дельта) передается не на диск, а по сети. После этого происходит операция resume уже на целевом хосте. Пользователь этого переключения, как правило, не замечает, так как время этого переключения очень жестко контролируется и чаще всего не достигает 1 секунды. Если память гостевой ОС будет меняться очень быстро, то vMotion может затянуться именно во время этого переключения (нужно передать последнюю дельту).

5. Горячая миграция хранилищ Storage vMotion. Здесь stun случается аж дважды: сначала vSphere должна поставить Mirror Driver, который будет реплицировать в синхронном режиме операции ввода-вывода на целевое хранилище. При постановке этого драйвера происходит кратковременный stun (нужно также закрыть диски). Но и при переключении работы ВМ на второе хранилище происходит stun, так как нужно удалить mirror driver, а значит снова переоткрыть диски уже на целевом хранилище.

В современных версиях vSphere работа со снапшотами была оптимизирована, поэтому подмораживания виртуальной машины во время этих операций вы почти не заметите.

Практически все администраторы виртуальных инфраструктур обеспокоены проблемой ее производительности в тех или иных условиях. На днях компания VMware обновила свое основное руководство по производительности платформы виртуализации номер один на рынке - Performance Best Practices for VMware vSphere 6.0.

Это не просто очередной whitepaper - это настоящая книга о производительности, на почти 100 страницах которой можно найти не только теоретические советы, но и вполне практичные настройки и конфигурации среды VMware vSphere. К каждому объясняемому параметру заботливо описаны рекомендуемые значения. В общем, Must Read.

Компания Nutanix, производящая программно-аппаратные решения для создания кластеров хранилищ под виртуализацию, опубликовала интересный постер, где приведены основные командлеты PowerShell для управления этими системами:

Ну а вот тут собрано еще несколько интересных документов от Nutanix.

Многие наши читатели интересуются, а есть ли утилиты, предназначенные специально для облачных инфраструктур. Например, которые позволяют оценить качество предоставления услуг сервис-провайдером? Да, есть такое, и одно из подобных средств - AppEnsure - как раз позволяет измерять время отклика для корпоративных приложений и текущую используемую пропускную способность.

Эта штука появилась еще весной в рамках программы Citrix Startup Accelerator, где было вот такое видео:

Теперь это полноценный продукт, с платным и бесплатным изданиями, который позволяет анализировать качество предоставления услуг облаком (частным или публичным) и искать причину падения производительности приложений.

Вот возможности бесплатной версии AppEnsure:

• Обнаружение приложений вашей инфраструктуры и их добавление в окружение мониторинга.
• Автоматическое построение топологии зависимости компонентов вашего приложения.
• Измерение по шагам (hop-by-hop) и полного (end-to-end) времени отклика, а также пропускной способности канала для каждого приложения.
• Возможность предоставления диагностической информации при снижении пропускной способности или увеличении времени отклика.
• Продукт AppEnsure (консоль и база данных) поставляется как готовый виртуальный модуль (VMware Virtual Appliance).
• Доступны как серверные, так и десктопные агенты для ОС Windows/Linux (до 5 серверов в бесплатной версии).
• Поддержка удаленных агентов (в другой сети или облаке по отношению к мастер-инсталляции).
• Доступ к веб-порталу технической поддержки.
• Сохранение данных в течение 24 часов (в платной версии - сколько угодно).

Вот так выглядит обнаруженная топология:

Так дэшборд приложения:

А вот так - общий дэшборд:

Ну и таблица сравнения изданий:

Загрузить бесплатную версию AppEnsure или попробовать платную версию продукта можно по этой ссылке.

Мы точно знаем, что вам всем интересно узнать, какова же реальная производительность продукта номер 1 для создания отказоустойчивых программных хранилищ StarWind Virtual SAN. Поэтому-то и приглашаем вас на бесплатный вебинар "Get Unbelievable Performance without Expensive All-Flash Arrays", где вы узнаете как достичь высокой производительности подсистемы хранения виртуальных машин, не покупая дорогостоящие All-flash хранилища.

Вебинар пройдет 16 июня в 21-00 по московскому времени. Мероприятие проводит продакт-менеджер StarWind Макс Коломейцев. Вопросы можно задавать на русском языке! Регистрируйтесь!

Это гостевой пост компании ИТ-ГРАД, предоставляющей услуги аренды виртульных машин в облаке.

Контейнерная виртуализация и специализированные облака — тренд нашего времени. Возможность выпускать приложение в унифицированном формате под любую платформу привлекательна сама по себе. А если добавить сюда открытость, поддержку всех основных систем виртуализации и фокус на разработчиков ПО, то получаем любопытное решение для поставщиков программного обеспечения и их клиентов. В этой статье поговорим о платформенном облаке Pivotal CF и поищем ответ на вопрос, зачем оно нужно.

Компания Pivotal — обособленное подразделение EMC, кoторое разрабатывает продукты для виртуализации и облачных вычислений. Наиболее известным из них можно назвать Pivotal Cloud Foundry, который предназначен для упрощения жизни разработчикам ПО. Pivotal предлагает некую абстракцию для всем привычной IaaS-виртуализации, когда ПО выпускается в виде своеобразного «строительного кубика» без привязки к платформе виртуализации. Напоминает контейнеры, правда? По сути идея очень близка, но имеет свои особенности.

Теперь любой разработчик может запустить свое приложение в среде Cloud Foundry, выбрав конкретное облако по желанию: vSphere, AWS или OpenStack. Подход сулит серьезную экономию времени и сил на предоставлении доступа заказчикам к новым разработкам. А возможность работы с облаками нескольких типов еще больше повышают гибкость и решения.

Платформенное облако

Pivotal CF — платформа для облачных систем, которая выступает в качестве некоего слоя абстракции для виртуальной среды (как виртуализация для виртуализации). Суть в том, чтобы создать унифицированную площадку, на которой можно запускать любые приложения без привязки к конкретному облаку или гипервизору. То есть строительным блоком служит не виртуальная машина, а контейнер приложения. На контейнерах подробнее остановимся чуть позже, а пока разберемся, чем CF лучше привычного облака PaaS.

Platform as a Service (PaaS) — модель предоставления облачных вычислений, при которой потребитель получает доступ к использованию информационно-технологических платформ: операционных систем, систем управления базами данных, связующему программному обеспечению, средствам разработки и тестирования, размещённым у облачного провайдера.

Фактически Pivotal предлагает прийти к любому облачному провайдеру с собственным облаком-платформой, которое ставится поверх всех популярных IaaS. Зачем нужно так усложнять и почему бы просто не создать десяток VM на той же vSphere? Все очень просто: а вдруг вы хотите работать с Amazon, а не VMware? Или нужно распределенное по миру решение, а услуги облачных провайдеров в разных странах отличаются по платформе или цене за нее. В конце концов, можно построить огромное распределенное облако сразу из нескольких типов IaaS и вообще ничем себя не стеснять...[кликните, чтобы читать дальше]

Интересная история произошла тут между компаниями VMware и Nutanix. Инженеры и сейлы из VMware решили провести сравнение производительности программных отказоустойчивых кластеров на базе локальных хранилищ серверов VMware Virtual SAN и Nutanix. Создав тестовую конфигурацию и выбрав профиль нагрузки, компания VMware сделала тест в средах Virtual SAN и Nutanix.

Кстати, вот конфигурация тестового кластера хранилищ:

• 4 x Dell XC630-10 для Nutanix,
• 4 x Dell R630 для vSphere с кластером VSAN
• 2 x Intel E5-2690 v3 на сервер
• 12 ядер на процессор 2.6GHz, 256 ГБ памяти на сервер
• Двухпортовый 10Gb Ethernet
• 1 x PERC H730 Mini на сервер
• 2 x 400GB Intel S3700 на сервер
• 6 дисков x 1TB 7200 RPM NL-SAS (Seagate) на сервер

Но тут спецы из VMware решили заглянуть в EULA Nutanix, а там написано (п. 2.1, подпункт e):

You must not disclose the results of testing, benchmarking or other performance or evaluation information related to the Software or the product to any third party without the prior written consent of Nutanix

То есть, публиковать результаты тестирования нельзя. Вот такой облом. А ведь VMware много раз ругали за то, что она сама запрещает публиковать результаты тестирования производительности с конкурирующими продуктами. Это также зафиксировано в EULA:

You may use the Software to conduct internal performance testing and benchmarking studies. You may only publish or otherwise distribute the results of such studies to third parties as follows: (a) if with respect to VMware’s Workstation or Fusion products, only if You provide a copy of Your study to benchmark@vmware.com prior to distribution; (b) if with respect to any other Software, only if VMware has reviewed and approved of the methodology, assumptions and other parameters of the study (please contact VMware at benchmark@vmware.com to request such review and approval) prior to such publication and distribution.

VMware, конечно, утверждает, что у нее условия мягче, но по-сути у них написано одно и то же. Публиковать результаты тестов без разрешения нельзя. А разрешение, конечно, никто не даст, так как опубликовать конкуренты захотят только, если у них все работает лучше и быстрее.

Поэтому VMware ничего не оставалось, как опубликовать результаты только своих тестов и разбить их по профилям нагрузки, отметив, что желающие сравнить пользователи сами могут убедиться, что Nutanix работает медленнее, проведя тесты самостоятельно.

Надо также отметить, что VMware отправила запрос на публикацию в Nutanix, на что получила ожидаемый ответ - публиковать нельзя.

Ну и, собственно, результаты тестирования для кластера Virtual SAN:

Совсем недавно компания VMware выпустила полезный документ "VMware Horizon View 6.0.2 and VMware Virtual SAN 6.0 Hybrid", описывающий эталонную архитектуру инфраструктуры виртуальных ПК Horizon View 6, которые хранятся в кластере отказоустойчивости VMware Virtual SAN 6.0, построенном на базе хостов VMware ESXi.

В документе рассмотрено тестирование производительности 12-узлового кластера Virtual SAN на базе серверов Supermicro в рамках следующей логической архитектуры:

Подробная конфигурация хостов:

В целом инфраструктура тестирования выглядела так:

Для тестов использовалось средство Login VSI (о нем мы уже много писали), которое поставляется вместе с методологией тестирования:

Сводные результаты тестов:

Для получения более подробной информации о результатах по каждому тесту, используемых сценариях и конфигурациях обращайтесь к документу. Все 38 страниц полны картинок, графиков и табличек с цифрами - док составлен очень по делу. Для тех, кто планирует VDI на базе Virtual SAN очень полезный референс, как в плане архитектуры, так и в плане производительности.

На днях компания VMware выпустила интересный открытый документ "Virtualizing Microsoft Applications on VMware Virtual SAN", в котором описываются результаты тестирования бизнес-критичных приложений Microsoft в кластере отказоустойчивых хранилищ VMware VSAN.

В документе рассматривается стрессовое тестирование следующих приложений, работающих в кластере Virtual SAN, состоящем из 8 узлов:

• Microsoft Exchange 2013 с поддержкой Database Availability Groups (DAG)
• Microsoft SQL Server 2014 с включенными AlwaysOn Availability Groups (AAG)
• Microsoft SharePoint 2013 как фронтэнд баз данных

Для теста использовалась такая конфигурация серверов:

• ESX host CPU - 2 x Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz 10C (60 GHz)
• ESX host RAM - 256 GB
• Network Adapter - 2x Intel Ethernet 82599EB 10-Gigabit SFI/SFP+
• Storage Adapter - 2x LSI Logic / Symbios Logic LSI-9300-8i
  • Firmware version: 6.00.00.00-IT
  • Driver version: MPT3SAS
• Power Management - Balanced (поставлено в BIOS)
• Disks SSD - 2x Intel 400 GB (SSDSC2BA400G3)
• SSD - 2x Intel 200GB (Intel PCIe 910)
• HDD - 12 x Seagate 900 GB

Конфигурация дисковых групп кластера Virtual SAN:

• Diskgroup 1 - 1x Intel 400GB 3x Seagate 900GB
• Diskgroup 2 - 1x Intel 400GB 3 x Seagate 900GB
• Diskgroup 3 - 1x Intel 200GB 3 x Seagate 900GB
• Diskgroup 4 - 1x Intel 200GB 3 x Seagate 900GB

Для тестирования Microsoft Exchange применялись следующие средства:

• Microsoft Exchange Load Generator 2013
• Microsoft Exchange Server Jetstress 2013 Tool (с использованием руководства Microsoft Exchange Server Jetstress 2013 Field Guide).

Архитектура сервисов Exchange:

Конфигурация виртуальных машин:

Результаты тестирования первого узла с ролью Mailbox средствами Jetstress:

Результаты тестирования второго узла с ролью Mailbox:

Результаты теста Load Generator:

Архитектура сервисов Microsoft SQL Server с технологией защиты данных Always On:

Для тестирования SQL Server использовался инструмент DVD Store. Конфигурация виртуальных машин:

Результаты тестов DVD Store.

Ну и в заключение - сводные результаты тестирования:

В итоге утверждается, что приложения Microsoft уровня Tier 1 прекрасно себя чувствуют в кластере VMware Virtual SAN, и их быстродействие мало чем отличается от ситуации, если бы на бэкэнде были аппаратные SAN/NFS-массивы.

За остальными подробностями обращайтесь к документу "Virtualizing Microsoft Applications on VMware Virtual SAN".

На днях компания VMware объявила о выходе обновленной версии средства для переноса физических компьютеров в виртуальную среду - vCenter Converter Standalone 6.0. Напомним, что прошлое большое обновление этого продукта вышло достаточно давно - vCenter Converter Standalone 5.5.1 был выпущен больше года назад (а в октябре прошлого года вышла версия 5.5.3).

Давайте посмотрим, что появилось нового в vCenter Converter 6.0, который органично вписывается в линейку продуктов на платформе vSphere версии 6.0:

• Поддержка виртуального аппаратного обеспечения (virtual machine hardware) версии 11.
• Полная поддержка vSphere 6.0 and Workstation 11.
• Поддержка новых гостевых ОС: Red Hat Enterprise Linux 7, Ubuntu 14, CentOS 6-7, Windows Server 2012 R2, Windows 8.1.
• Поддержка сетевых окружений, полностью построенных на базе протокола IPv6.
• Режим работы через прокси-сервер.
• Клонирование данных на уровне файлов для томов файловой системы ReFS в ОС Windows.
• Поддержка файловой системы XFS.
• Поддержка прописанных заранее имен сетевых интерфейсов.
• Исправления ошибок и улучшенная стабильность.

Кстати, заявляется о том, что данная версия vCenter Converter является последней, которая поддерживает сторонние образы и виртуальные машины других платформ в качестве источников для конверсии. Следующая версия Converter будет предназначена только для конверсии изнутри ОС в режиме миграции P2V. Учитывайте это при планировании проектов по миграции систем.

Основной документ VMware vCenter Converter Standalone 6.0 User's Guide можно скачать по этой ссылке. Сам продукт vCenter Converter Standalone 6.0 можно загрузить здесь.

На днях компания VMware сделала пару интересных анонсов в сфере облачных вычислений. Одним из таких анонсов стал Project Photon - легковесная ОС, построенная на базе Linux-ядра, предназначенная для использования в облачных инфраструктурах.

Project Photon - это ОС для так называемых cloud-native applications, то есть приложений, изначально созданных для облачной инфраструктуры и запакованных в контейнеры виртуальных машин. Напомним, что VMware уже делала шаги в этом направлении с инициативой CoreOS, а также интеграцией с механизмом Docker (также см. вот тут). Теперь же VMware дошла и до создания своей ОС на базе компонентов с открытым исходным кодом, чтобы обеспечить пользователям полный набор инструментов для создания приложений, которые просто масштабируются в облачной среде.

Project Photon будет обладать следующими возможностями:

• Поддержка большинства форматов Linux-контейнеров приложений, таких как Docker, rkt и Garden от компании Pivotal (дружественная VMware компания, ее директор, Пол Мориц, был раньше директором VMware).
• Минимальный размер машины на диске (около 300 МБ).
• Инструменты для миграции приложений в контейнерах из среды разработки в производственную среду.
• Возможности обеспечения безопасности, централизованного управления и оркестрации операций на базе инструментов, доступных для платформы VMware vSphere.

Обзор решения Project Photon для запуска контейнеров на базе движков Docker и Rocket Containers (от создателей CoreOS):

На данный момент код Project Photon доступен для всех желающих на GitHub. Вот тут можно прочитать небольшой обзор процесса развертывания.

Одновременно с Project Photon был запущен и Project Lightwave, который призван решать задачи аутентификации и управления доступом в среде контейнеризованных приложений с сотнями пользователей. Это средство позволит централизованно управлять идентификацией пользователей через интеграцию с VMware vSphere и vCloud Air, а также осуществлять управление сертификатами и ключами в облачной среде. Lightwave поддерживает большинство открытых стандартов в области аутентификации и обеспечения безопасности, таких как Kerberos, LDAP v3, SAML, X.509 и WS-Trust.

Демонстрация работы решения Project Lightwave:

Код проекта Project Lightwave также будет доступен как Open Source в репозитории на GitHub. Его финальный релиз ожидается через несколько месяцев.

Не так давно мы писали про средство Login VUM, которое позволяет в реальном времени создавать нагрузку в виртуальном ПК для различных приложений (то есть открывать окна, выполнять некоторые операции), будто бы за этой виртуальной машиной работает реальный пользователь. Далее, если время выполнения стандартных операций превышает некоторые пороговые значения (например, приложение запускается слишком долго), Login VUM оповещает системного администратора о возникшей проблеме. Из коробки измеряется время запуска таких приложений, как Microsoft Office, Internet Explorer и Adobe Reader, но скрипты можно настроить на использование любых приложений.

Теперь компания Login VSI выпустила финальную версию этого решения, которое теперь называется Login PI.

Основные варианты использования Login PI:

• Мониторинг производительности продуктивных окружений без влияния на работающие системы предприятия.
• Оповещения о снижении производительности VDI-инфраструктуры (неважно, Citrix, VMware или другого вендора).
• Регулярное тестирование VDI-среды для понимания ее текущего уровня производительности и занятости ресурсов.

Интересный момент - Login PI можно протестировать в реальном времени (hands-on lab) прямо на сайте Login VSI. Для этого нужно заполнить форму вот тут, после чего вам предоставят доступ к тестовой лаборатории, где вы сможете самостоятельно поработать с данным продуктом, управляя консолями двух виртуальных машин:

Руководство по использованию этой тестовой лаборатории можно почитать вот тут.

Login PI основан на фреймворке Login VSI (технология измерений VSImax), который уже надежно зарекомендовал себя для задач тестирования инфраструктуры виртуальных ПК (об этом мы писали ранее). Для запроса 30-дневной триальной версии Login PI используйте вот эту ссылку.

Как вы знаете, в обновленной версии платформы виртуализации VMware vSphere 6.0 появились не только новые возможности, но и были сделаны существенные улучшения в плане производительности (например, вот).

В компании VMware провели тест, использовав несколько виртуальных машин с базами данных SQL Server, где была OLTP-модель нагрузки (то есть большой поток небольших транзакций). Для стресс-теста БД использовалась утилита DVD Store 2.1. Архитектура тестовой конфигурации:

Сначала на хосте с 4 процессорами (10 ядер в каждом) запустили 8 виртуальных машин с 8 vCPU на борту у каждой, потом же на хосте 4 процессорами и 15 ядер в каждом запустили 8 ВМ с 16 vCPU. По количеству операций в минуту (Operations per minute, OPM) вторая конфигурация показала почти в два раза лучший результат:

Это не совсем "сравнение яблок с яблоками", но если понимать, что хосты по производительности отличаются не в два раза - то результат показателен.

Интересен также эксперимент с режимом Affinity у процессоров для "большой" виртуальной машины. В первом случае машину с 60 vCPU привязали к двум физическим процессорам хоста (15 ядер на процессор, итого 30 ядер, но использовалось 60 логических CPU - так как в каждом физическом ядре два логических).

Во втором же случае дали машине те же 60 vCPU и все оставили по дефолту (то есть позволили планировщику ESXi шедулить исполнение на всех физических ядрах сервера):

Результат, как мы видим, показателен - физические ядра лучше логических. Используйте дефолтные настройки, предоставьте планировщику ESXi самому решать, как исполнять виртуальные машины.

Больше информации об этом тесте можно узнать из документа "Performance Characterization of Microsoft SQL Server on VMware vSphere 6".

Как вы знаете, недавно вышла новая версия платформы виртуализации VMware vSphere 6.0, для которой было также обновлено средство создания кластеров хранилищ VMware Virtual SAN 6.0 на базе локальных дисков серверов. Среди прочих новых возможностей VSAN, было сказано об улучшении производительности решения, что и решили проверить коллеги на тестах вот тут.

Тест проводился дома и не претендует на какую-либо достоверность, но, все же, его весьма интересно посмотреть. Автор взял 3 узла Shuttle SZ87R6 следующей конфигурации (надо отметить, что они не в HCL):

В качестве коммутатора использовался Cisco SG300.

Для тестирования были использованы следующие гипервизоры:

• ESXi 5.5 Update 2 (build 2068190)
• ESXi 6.0 (build 2494585)

В качестве средства создания нагрузки взяли IOmeter, размещенный в виртуальной машине с двумя vCPU, 4 ГБ памяти и Windows Server 2012 в качестве гостевой ОС. Было также сконфигурировано 2 дополнительных виртуальных диска на контроллере PVSCSI:

Для IOmeter было создано три профиля нагрузки, размер Working Set - 100 МБ (204800 секторов). Малый размер Working Set был выбран для более быстрого прогрева кэша.

Результаты (кликабельно):

Как мы видим, VSAN 6.0 показал себя лучше при всех типах нагрузки - выжимает больше IOPS и имеет меньшую задержку (latency), а именно:

• Нагрузка 100% READ | 100% RANDOM: +37% IOPS | -27% latency
• Нагрузка 65% READ | 60% RANDOM: +53% IOPS | -35% latency
• Нагрузка 100% WRITE | 100% RANDOM: +25% IOPS | -24% latency

Производительность снапшотов

VSAN 5.5 (он же 1.0) использует формат vmfsSparse, который, по-сути, является redo-логом. В версии VSAN 6.0 появился новый формат снапшота vsanSparse, который использует механизм redirect-on-write (подробнее тут).

Тест проводился просто - запустили IOmeter (профиль 3) и последовательно снимали снапшоты, наблюдая производительность с помощью VSAN Observer.

Светло-серые картинки - это VSAN 1.0 (5.5), а темно-серые - VSAN 6.0 (кликабельно). Обратите внимание, что значения по осям X и Y на картинках не всегда соответствуют.

Итак, Latency:

Кстати, временами по latency VSAN 6.0 хуже своей предыдущей версии.

По IOPS результаты интереснее:

При создании нагрузки в виде снапшотов VSAN 6.0 снижает производительность по IOPS на 8%, а вот предыдущая версия VSAN - на 49%. Преимущества нового формата очевидны.

Полоса пропускания (Bandwidth):

Интересный эффект - в VSAN 1.0 существенно увеличивается трафик на чтение после снятия каждого снапшота, при этом у VSAN 6.0 такого не происходит. Еще одно улучшение Virtual SAN 6.0.

В целом можно отметить, что производительность кластеров VSAN заметно возрасла, ну а оптимизация снапшотов улучшит и производительность процессов, использующих эту технологию (например, резервное копирование).